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This Is a working paper on the KLIO ICCS port design. It is 
not intended to be a complete functional or design 
specification but ratner a departure point for identifying 
the areas of concern and technical Interest, 

The KLIO ICCS port will provide a VAX-compatible interface 
to the ICCS bus. The port has three important interfaces* 

1, Software to port control. This Interface is 
used to request data transmission, post completion, 
and transmit status. This interface will be 
implemented with the standard PDP-iO I/O 
instructions, 

2, The port to linK interface. This Interface is 
specified by the corporate interconnect 
specification and is beyond the scope of this 
specification, 

3, The port to memory interface. This interface 
allows the port to reference and to modify the host 
memory. This Interface has two divisions: 

a. The DHA interface for transferring data 
to ana from the link. This interface will 

be via the C-BUS, 

b. The E-BUS interface for queue 
manlpulationsr and packet fetch and store. 
This will be implemented via the E-BUS lOP 
functions. 

The principal goal is to implement the VAX port architecture 
in TOPS20 and in the KLIO port and provide a transparent 
migration to the 2080 interface. 

Since the Implementation will be compatible with the VAX 
port spec, and since that architecture is well-documented 
[13, this specification will be concerned with differences 
between the VAX port spec and the KLIO implementation as 
well with KLlO-speciflc operations. 

1.0 initialization 

The monitor will intlalize the port operation by indicating 
the port's PI level and the address of the Port control 
block(PCB) Csee section 6 of tlJ), In order to facilitate 
the port's Interface via the E-BUS, the KLIO oort control 
block is as folio*(S (ail words are 36-bit words) 



word ottset description 

physical address of BDT 

1 Free queue interlock word 
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2 

3 
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10 

11 
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14 

15 

16 

17 

IB 



Free queue for 
Free queue bac 
Coffli^and queue 
Command queue 
Command queue 
Command queue 
Command queue 
Command queue 
Command queue 
Command queue 
Command queue 
Command queue 
Command queue 
Command queue 
Response queue 
Response queue 
Response queue 



ward pointer 
K pointer 
Interlock word 
forward pointer 

back pointer 

1 mteriocic word 
1 forward pointer 

back pointer 
Interlock word 
forward pointer 
pack pointer 
Interlock word 
forward pointer 
back pointer 
Interlock word 
forward pointer 
back pointer 



The buffer descriptor table indicated by offset of the PCa 
is as follows: 



wor'i 



description 



y count of number of BDT entries 

1 to 2*n n t*o-word entries (eacn entry, 

if valid, points to the buffer 
descriptor (bO) for tnls entry 
(see section 2,1), 

The port control block will be Identified to the port via a 
DATAO that specifies the physical address of the block. 

In order to implement the Interlock function, the port needs 
the followlnq capabilities: 



1. The ability to read a memory location and to 
simultaneously modify it, i>ione of tne existing lOP 
functions provide this an an atomic operation. It 
is recommended that the "increment" lOp function 
(function code 3) be modified to both Increment the 
memory location and to drive tne resulting value 
back onto the £-bus, in this way It becomes a true 
AGS function. 
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The manipulation of the queues is straight-forward and in 
accordance with the algorithms in [13. 

1,1 Command queues 

The port and tne monitor maintain four distinct command 
queues. Each command queue has its own interlock word and 
list pointers. Furthermore each command queue has an 
implicit priority assignment with queue oeing the highest 
priority and queue 3 being the lowest. 

The priorities are used to control the execution of 
commands. Commands fall into three general categories: 

a. Commands requested by the local host. These are 
corcmands placed on a command queue directly by tne 
local operating systems. 

b. Data transfers initiated by the local host. 
This differs from the previous category in that a 
single command causes a block data transfer with a 
DMA-llKe mechanisB), 

c. Data transfers initiated by a remote nost. 
Again, this is accomplished with a command, but 
requires additional resources by way of the D«A data 
transfers mechanise. 

[ The various priority levels may be used to sequence the 
execution of these types of commands in the most expeditious 
manner, 

I 

2.0 Sending messages and data 

The procedure for sending messages and data is described in 
C13, The BDT and packet formats in 113 are not appropriate 
for the needs of T0PS20, however, and need to be modified as 
follows: 

2.1 Buffer descriptor formats 

A buffer descriptor CBU) consists of a linked list of 

descriptors each of v^hlcn describes a region of physical 

memory, BDs are described by entries in the ouffer 

descriptor table. Each individual descriptor has the 
following format; 

word contents 

pnyslcal aadress of next descriptor 

1 tnode(3), count(J5), offset In buffer (18) 

2 physical address of base of data buffer 

3 port-available storage and final status 

The head of the Bn chain (i.e. the BDT Itself) Is located 
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in the BDT and is as follows: 

word contents 

valid bltCUr buffer icey (16), modifier (2) , port 

1 pnysical address of head of BD chain 

Each BDT identlfer given out by T0PS20 will be the offset 
from the start of the BDT table in the PDB, Therefore the 
address of the BDT header isj 

BDT8+2*(n-l) 

where 

BDTB is the base address of the start of the BDTs and n is 
the descriptor specified in the data request. For n to be 
valid, it must be less than the number of BDT entries 
specified in the pcb. 

Note that the BD has been designed so that all of the 
verification information is in one word. Since tne port 
must verity tnat the requesting port has tne right to use 
the selected buffer, this procedure may be performed by 
fetching only one word trow pdpIO memory. 



2.2 Messages 




Given this restriction, it seems logical to define a message 
as being coincident with that defined tlJ. This implies 
that messages will contain "byte" data but may identify BDs 
tnat aadress worn data. 



To simplify the handling of these message packets, the first 
three words of each pacKet *lli be interpreted as containing 
36-blt data, and the message body as containing byte data. 
That is, the linic pointers and internal flags and control 
information *iil use all 3fc-blts of eacn word, ine message 
body will use tne left-most 32 bits of each word (Since the 
contents of the first three words are not transmitted over 
tne bus, this presents no conflict with the Interface 
requeirements) • 
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3,0 C-BUS Interface 

When the port needs to have DMA access to memory* it v»ill 
use the C-BUS to reference its data. That is, the port will 
appear to oe an RH20 and consequently needs to manipulate 
the appropriate EPT locations to control the internal 
Channel It Is "borrowing". This access is via the lOP 
functions of the E-sus, 

4.0 10 instructions 

The following 10 instructions are defined for the port: 

CONO PRT, 

bits definition 

33-35 CRW) PSI level 

32 (i«) enable PSI 

31 (KW) GO 

30 (R*») Stall 

29 (R) memory parity error detected 

28 tKj unrecoveraoie uus error 

27 (R) Free queue empty (message ovverrun) 

(w) Clear errors 

2fe (^) Command queue loaded 

25 (RW) Response queue non-empty 

24 Clear cache 

GO bit: This bit is on whenever the port is active 
processing a request, if it is set on a CONO, it causes the 
port to poll the request queues for some worJc to do. 

Stall: This bit is used to shutdown the port. If Stall is 
set, the port will complete its present operation and then 
clear GO and enter the Idle state. Any new requests that 
arrive should be rejected. Setting GO clears Stall. 

Response queue non-empty: This is asserted by the port when 
it inserts an entry on an empty response queue. 

Command queue loaded: The software will assert this bit 
Whenever it places an entry on an empty command queue, i*«nen 
this is asserted, the port should note that the command 
queue needs to foe polled. The monitor may not assert this 
bit when it places an entry on a non-empty command queue 
(Since the port can place a message on the coitimand queue 
Itself, it Should not rely on this bit being asserted to 
begin command queue processing, in this case, however, the 
port coul<i assert tne bit itself,). 

Clear cache: Since the port needs to matce frequent 
reference to memory, it is llKely it will implement some 
form of memory cache to avoid the overhead of typical memory 
references. The monitor will assert this bit whenever it 
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wishes to invalidate a buffer descriptor and the Port should 
respond by flushing from its local memory any knowledge of 
extant buffer descriptors. Since the monitor never 
unilaterally invalidates the queues without resettlna the 
port# any cached queue information may be retained. 

The error bits may need expanding with time, 

note: The "reset" state of the port should be that Stall is 
set and GO is off. This state is entered whenever an 10 
reset is issued or a DATAO PRT, is issued. This feature 
precludes the port's clobbering memory while BDTs are being 
established and allows the software to determine if a port 
exists without changing its state. 



4,1 CSRs 

The port CSR registers are read and written via paTAi and 
DATAO instructions. Each CSR has a distinct function and Is 
selected by a DATAO to "select CSR register", 

4.1.1 Lodu tC5 i>c*se ddaiesb aiiu PCS C5k 

CSR 00 (Rw) PCS base address 

Tnls tunctlen is iisea to reset the port and declare the port 
descriptor block. The argument is the pnyslcal address of 
the descriptor biocK, if this function is Issued while the 
port is active, the port should immediately shutdown and 
enter the "reset" state, 

4.1.2 CSR 01 (RW) Port configuration register 

This CSR contains: 

port i,d, (R) 

number of busses present (R) 

busses enabled (RW) 

Dus selection mode (R«i) 

The bus selection mode indicates whether the busses are 
selected explicitly oy the softm-are (nigh performance mode) 
or are considered as one bus and may be used as the port 
desires (high availability mode). The active busses and the 
bus selection mode !"ay be modified by the software. The 
"reset" state ol tne bus Is to enable all connected bus -and 
to employ the hinh availability mode for bus selection, 

4.1.3 CSks 02-1 u (Hvv) port pert ormance meters 
IDS 

4.1.4 CSH 11 (R) port error register 
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This CSR contains detailed Information on any port, linK or 
bus detecteo errors, 

4.1.4 Other CSRs 

Ail unspecified CSR registers are reserved to DEC. 

4.2 Issues 

An irtiportant issue is the manner In which diagnostics will 
access the port, i«e may want to include a rich collection 
of status and condition flags so that It is possible to 
exercise the port without having to use the spelcifed queue 
structures, 

4.3 Caching of port data 

As mentioned earlier, the port may want to provide a cache 
for its data to avoid the overhead of constantly referenclnq 
main fpemorv. Such a cache can contain bD, BDT and queue 
entry data that the port is likely to need. 

It seems quite reasonable to caciie BD and BOI data since 
these are the most performance sensitive as well as 
frequently neeaed data items. Buffer descriptors^ once set 
up by the software, will not change as long as the ouffer 
descriptor remains valid. 

Caching queue entries is risjcy and possibly not justifiable 
considering the care that must oe exercised. However, if it 
is possible to cache any portion of the queue data oase, the 
performance gain is certainly welcomed. 

Some careful thought should be given to this feature since 
its effectiveness will liJcley have a significant effect on 
the efficiency and performance of the port, 

5,0 Data modes and modifiers 

The data modes supported by the KLIO port are: 

byte mode. Data is packed as 

eight-bit bytes occupying the 

left-most 32-bits of each memory 
word 

1 word rrode. Data is packed using all 

36-blts of each memory word, when 
word data is transmitted or received 
over the bus, it is packaged as a 
series of «-blt bytes. If the data 
sent is not an integral number of 
bytes (i.e,, the word count is odd), 
then the last byte Is zero-filled. 
If the data received Is not an 
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Integral number of words, any extra 
bits are discarded, 

2 Tape mode. This mode requires that 

each word be transmitted or received 
as five bytes of data. The 
low-order four bits of the last byte 
Cthe first four received or 
transmitted) are zero-filled. 

In each BDT is a fnodifler field. The defined values are: 

i Read-only 

2 Read backwards 

3 write-only 

4 write backwards 

The rrodlfier Indicates the type of operation that may be 
requested on tnis buffer and the direction the data is to oe 

accessed. 

e>,u Programming considerations 

The information up to now has been aimed at understandlnq 
how the KLlO ICCS port will operate. Several Important 
points must be noted; 

1, The addresses that the port uses are all 
physical memory addresses. This means that the 
queue pointers and headers must contain physical 
addresses. This has been done to make the port's 
memory references be Independent of the m-bOX, pager 
refills, and various types of paging failures that 
may occur. The KLIO port could be built to deal 
with EXEC virtual addresses, but the 2080 appears 
not to have that flexibility. 

2, The construction of BDTs and BDs is complicated. 
Processing and verification of these tables will be 
costly for both the port and the monitor. 

These two points indicate tnat a unique apporach to creating 
the monitor's port driver must be considered. In 
particular, it is Important that the monitor be able to 
enqueue and dequeue command and response messaqes from the 
appropriate queues quickly. Several techniques are 
possible: 

1, Ensure tnat the PCB is in a page that is mapped 
virtual to Physical. That is. If the PCB is in eXEC 
virtual page lOO, then It must also be in physical 
paqe 100, It Is also necessary to allocate Bus from 
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pages with the same property. This restriction will 
not apply to the 2080 as It will Provide 
Instructions that implement physical addressing, 

2, Since the monitor knows the virtual address of 
the PCS, It can always reference it quickly. 
However* since it cannot predict which packet it 
needs to dequeue next, it needs a quick means of 
translating the physical address to a virtual one. 
The most straight-forward technique is for the port 
driver to have a virtual address slot it may use for 
temporary mapping (the same kind of slot used in 
PAGEM e.g. CXBPG), i»hen it needs to examine a 
packet, it would map the physical page to its page 
slot, perform any data modifications or extractions, 
and clear the map slot. Since all queue headers and 
interlock words are in fixed locations they can 
always be referenced *lth virtual addresses. 

Despite the fact that the monitor always processes 
queues FIFO, it still needs to maintain both forward 
and backward queue pointers since the port 
reterences queues ranaomiy. inertore, enqueuing or 
dequeueinq a packet requires modifying another 
packet as *ell as a queue header. To make this as 
efficient as possible, two temporary map slots could 
be allocated, 

3, Building in some other innate knowledge about 
BDs that would enable rapid conversion of physical 
addresses into virtual ones. An example would be to 
allocate all BDs from a single exec virtual page 
thereby making the word offset in the physical page 
the unique identlfer of the packet's location. 
Multiple pages could be used with another level of 
translation required, 

i The first technique seems adequate for the KLIO, The 2080 
provides sufficient flexibility in its addressing modes that 
the problem disappears. 
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This Is a wording paper on the KLIO ICCS port design. It 
is not intended to be a complete functional or design 
specification but rather a departure point for 
identifying the areas of concern and technical interest. 

The KLIO ICCS port win provide a VAX-compatible interface 
to the ICCS bus. The port has three important interfaces; 

1, Software to port control. This interface 
is used to reguest data transmission, post 
completion, and transmit status. This 
interface will be implemented with the 
standard PDP-10 I/O instructions. 

2, The port to linK Interface. This interface Is 
specified by the corporate interconnect specification 
and is beyond the scope of this specification, 

3, The port to memory interface. This interface 
allows the port to reference and to modify the 
host memory. This interface has two divisions: 

a. The DMA interface for transferring 
data to and from the link. This interface 
will be via the C-6US. 

b. The E-BLiS interface for gueue 
manipulations, and packet fetch and 
store. This will pe ImpieTiented via 
the P-BUS lOp functions. 

The principal goal is to implement the VAX port architecture 
in T0PS20 and in the KLIO port and provide a transparent 
migration to the 20yu interface. 

Since the implementation will be compatible with the 
VAX port spec, and since that architecture is well-documented 
[13, this specification will be concerned with differences 
between the VAX port spec and the Kliio implementation as 
well with KLlO-specif ic operations, 

1,0 Initialization 

The monitor «ill Intlalize the port operation by 
indicating the port's PI level and the address 
of tne Port control blockfPCB) (see section 8 of [IJJ, 
In order to facilitate the port's interface via the 
E-BUS, the KLIO port control plocic is as follows (all 
words are 3f.-bit words) 

.literal 

wora ottset aescription 

pnysicai address of BUT 

1 Free gueue InterlocK word 

2 Free gueue forward pointer 

3 Free gueue bacsc pointer 

4 Command queue interlock word 

5 Command gueue forward pointer 



6 Comstand queue bacfc pointer 

7 Command queue 1 interlock; word 

8 Command queue l forward pointer 

9 Command queue 1 back pointer 

10 Command queue 2 interlock word 

11 Command queue 2 forward pointer 

12 Command queue 2 bacK pointer 

13 Command queue 3 interloclc word 

14 Command queue 3 forward pointer 

15 Command queue 3 c>ac< pointer 

16 Response queue interlock word 

17 Response queue forward pointer 

18 Response queue bacic pointer 

.end literal 

The buffer descriptor table indicated by offset of 
the PCB is as follows: 

•literal 

word description 

count of number of BDT entries 

1 to 2»n n two-word entries (each entry, 

if valid, points to the buffer 

uescriptor ibu) fur tnis eatiy 
tsee section 2,1J. 
,end literal 

The port control block wiii he Identified to the 
port via a DATAU that specifies the physical address 
of the block. 

In order to implement the interlock function, the port needs 
the following capabilities: 

1, The ability to read a memory location 
and to simultaneously modify it. None of 
the existing lOP functions provide this 

an an atomic operation. It is recommended that 
the "increment" lOP function (function code 3) 
be modified to both increment the memory 
location and to drive the resulting value 
back onto the E-bus. In this way it becomes 
a true AOS function. 

2, The ability to detect that the interlock 

is unavailable and to try aqain later. In order 
not to monopolize the processor, the retry algorithm 
should have a reasonable time delay. Once the monitor 
Interface Is desiqned, an estimate of the monitor's 
Interlockea path can be made. If the TOP increment 
tunction is .aoaified, toen tne port can detect 
if the interlock has been achieved by examining 
the returned data, A zero indicates successful 
Interlock, anything else indicates a failure. 

The nrianipulation of tne queues is straiqnt-f orwara and 
In accordance with thp aiqorithfTis in CD, 



1,1 ComiTiand queues 

The port and the monitor maintain four distinct command queues. 
Each command aueue has its own Interlocic word and list pointers. 
Furthermore each command queue has an implicit priority assignment 
with queue being the highest priority and queue 3 being the 
lowest. 

The priorities are used to control the execution of commands. 
Commands fall into three general categories: 

a. Commands requested by the local host. These 
are commands placed on a command queue directly 
by the local operatlnq systems. 

o. Data transfers initiated by the local host. 
This differs from the previous category in that 
a single conmiand causes a block data transfer 
with a DMA-like mechanism. 

c. Data transfers initiated by a remote host. 
Again, this is accomplished with a command, 
but requires adaltional resources by way of 
the DMA data transfers mechanism. 

The various priority levels may be used to sequence the 
execution of these types of commands in the most expeditious 

manner, 

2.0 Sending messages and data 

The procedure for sending messages and data Is described 
in Hi, The BDT and packet formats in tl] are not appropriate 
for the needs of TOPS20, however, and need to be modified 
as follows: 

2.1 Buffer descriptor formats 

A buffer descriptor (BD) consists of a linked list of descriptors each of 
which describes a region of physical memory, BDs are described 
by entries in the buffer descriptor taole. Each Individual 
descriptor has the following format: 

.literal 

word contents 







physical address of next descriptor 

1 mode(3), countClS), offset in buffer (18) 

2 physical address of case of data buffer 

3 port-available storage and final status 

,enri literal 

The nead of the BO cnain Ci,e, the BDT itself) is located In the hot and is as foil 

, literal 

word contents 

valid oit(l), buffer Key (16), mofHf ier(2) ,port 

1 physical address of head of BD chain 



.end literal 

Each 8DT identlfer given out by TOPS20 will be the 
offset froTi the start of the BDT table In the PDB, 
Therefore the address of the 8DT header is: 

MUlB+2*(n-l) 

where 

BDTB is the base address of the start of the BDTs and 
n is the descriptor specified in the data request. 
For n to be valid, it must be less than the number 
of BDT entries specified in the PCB. 

Note that the BD has been designed so that all of the verification 
information is in one word. Since the port must verify that 
the requesting port has the right to use the selected 
buffer, this procedure may be performed by fetching only 
one word from PDPIO memory. 

2.2 Messages 

A message, as defined in [IJ, is a fixed-sized pacicet 

of data tnat Is trans'.itted ato.nicdlly over the ous. 
Messages hs^e the peculiar property of being generated either 
by the host software Cin this case, TOPSaO), by the port 
itseit (to generate a reauest for data), or by tne reinote 
bort (to signify completion, or to request data). 
Therefore, there cannot be a iKLlO-specif ic format for messages 
that conflicts with messages generated and expected 
by other ports on the bus. 

Given this restriction, it seems logical to define a message 
as being coincident with that defined Hi, This implies 
that messages will contain "byte" data but may identify 
BDs that address word data. 

To simplify the handling of these message packets, tne first 

three words of each packet will be Interpreted as containing 

36-blt data, and the message body as containing 

byte data. That is, the link pointers and Internal 

flags and control information win use all 36-bits of 

each word. The message body n-ill use the left-most 

32 bits of each word (Since the contents of the 

first three words are not transmitted over the bus, 

this presents no conflict with the Interface* reouelrements) , 

3,0 C-BUS Interface 

When the nort needs to have 0^P> access to memory, 

it wMl use the c-B!is to reference Its data. That 

is, the port *'lll appear to be an RH20 and consequently 

needs to manipulate the appropriate EPT locations 

to control the internal channel it is "borrowing". 

This access Is via the TOP functions of the E-bilS, 

4,0 10 instructions 



The followinq 10 instructions are defined for the portj 

COWn PRT, 

bits definition 

33-35 (Rm) PSI level 

32 (W) enable PSI 

31 (RH) GO 

30 (RW) Stall 

29 (R) memory parity error detected 

28 (R) unrecoverable bus error 

27 (R) Free queue empty (message ovverrun) 

(W) Clear errors 

26 (W) Command queue loaded 

25 CRW) Response queue non-empty 

24 Clear cache 

GO bltj This bit is on whenever the port is active 
processing a request. If It is set on a CONO, it 
causes the port to poll the request queues for some 
work to do. 

Stall! This bit is used to shutdown the port. If Stall 

is set, trie port >viii complete its present operation 

and then clear GO and enter the idle state. Any new requests 

that arrive should be rejected, setting GO clears 

Stall. 

Response queue non-empty: This is asserted by the port 
when it inserts an entry on an empty response queue. 

Command queue loadedi The software will assert this bit 

whenever it places an entry on an empty command queue. When 

this is asserted, the port should note that the command queue 

needs to be polled. The monitor may not assert this bit when 

it places an entry on a non-empty command queue 

(Since the port can place a message on the command queue 

Itself, it should not rely on this bit being asserted 

to begin command queue processing. In this case, however, the 

Port could assert the bit itself,). 

Clear caches Since the port needs to maJce frequent reference 

to memory, it is likely it will implement some form 

Of memory cache to avoid the overhead of typical 

memory references. The monitor will assert this 

bit whenever it wishes to invalidate a buffer descriptor 

and the port should respond by flushing from Its local 

memory any knowledge of extant buffer descriptors. 

Since the monitor never unilaterally invalidates the 

queues without resettlnq the port, any cached queue 

Information fnay be retained. 

The error bits tr.av need expanding '*lth time. 

NOTej The "reset" state of the port should be 

that Stall is set and GO is off. This state is entered 

whenever an in reset is Issued or a DATAo PRT, 

Is issued, mis feature precludes 



the port's clobbering memory while BDTs are being established 
and allows the software to determine if a port exists without 
changing its state. 

4.1 CSRs 

The port CSR registers are read and written via DATAI and DATAO 
Instructions, Each CSR has a distinct function and is selected 
by a DATAO to "select CSR register". 

4.1.1 Load PCS base address and PCS CSR 

CSk 00 (Rrt) PCS base address 

This function Is used to reset the port and declare the 
port descriptor biocic. The argument is the physical 
address of the descriptor blocR. If this function is Issued 
while the port Is active, the port should Immediately 
shutdown and enter the "reset" state, 

4.1.2 CSR 01 (R»«) Port configuration register 
This CSR contains! 

port l.d, (H) 
.break 

number of busses present (R) 
.break 

busses enabled (RW) 
.break 

bus selection mode (RW) 

The bus selection mode Indicates whether the busses are selected 
explicitly by the software (high performance mode) or are considered 
as one bus and may be used as the port desires (high availability 
mode). The active busses and the bus selection mode may 
be modified by the software. The "reset" state of the bus 
Is to enable all connected bus and to employ the 
high availability mode for bus selection, 

4.1.3 CSRs 02-10 (RW) port performance meters 
TBS 

4.1.4 CSR 11 (R) port error register 

This CSR contains detailed information on any port, 
link or bus detected errors. 

4.1.4 other CSRs 

All unspecified Cft^ registers are reserved to ufcc. 

4.2 issues 

An important Issue is the manner In which diagnostics will 
access the port, -se may want to include a rich collection 
of status and condition fiaas so that it Is Dossloie to 
exercise the port without having to use the spelcifed 



queue structures. 

4,3 CacMnq of port data 

As mentioned earlier, the port may want to provide a cacne 
for its data to avoid the overhead of constantly referencing 
main mernory. Such a cache can contain 8D, BDT and queue 
entry data that the port is llicely to need. 

It seems quite reasonable to cache 8D and BDT data since 
these are the most performance sensitive as well as 
frequently needed data Items, Buffer descriptors, once set 
UP by the software, will not change as lonq as the buffer 
descriptor remains valid. 

Caching queue entries is risky and possibly not justifiable 
considering the care that must be exercised. However, if it 
is possible to cache any portion of the queue data base, the 
performance gain is certainly welcomed. 

Some careful thought should be given to this feature since 
its effectiveness will llKiey have a significant effect on 
the efficiency and performance of the port, 

5.0 Data modes and modifiers 

The data modes supported by the KLIO port are: 

oyte mode. Data is packed as elght-nit 

bytes occupying the left-'^ost 32-bits 
of each memory word 

1 word mode. Data is packed using all 

36-blts of each memory word. When word 
data is transmitted or received over 
the bus, It is packaged as a series 

of 8-bit bytes, if the data sent Is not 
an integral number of bytes (I.e., the 
word count is odd), then the last byte 
is zero-filled, if the data received 
is not an integral number of words, 
any extra bits are discarded. 

2 Tape mode. This mode requires 

that each word be transmitted or 
received as five bytes of data. The 
low-order four bits of the last byte 
(the first four received or transmitted) 
are zero-filled. 

In each BDT is a modifier field. The defined values are: 

1 Read-only 

2 Read backwards 

3 v^rite-only 

4 Write backwards 



The modifier Indicates the type of operation that may 
be requested on this buffer and the direction the data 
Is to be accessed. 

6,0 Programming considerations 

The information uo to now has been aimed at understanding 
how the KUIO ICCS port >*ill operate. Several important 
points must be notedj 

1. The addresses that the port uses are ail 
physical memory addresses. This means that the 
queue pointers and headers must contain 
physical addresses. This has been done 

to mat<e the port's memory references be independent 

of the M-BOX, pager refills, and various 

types of paging failures that may occur. 

The KLIO port could be built to deal 

with EXEC virtual addresses, but the 2080 

appears not to have that flexibility, 

2, The construction of HDTs and BDs is complicated. 
Processing and verification of these tables 

will be costly for both the port and the 
monitor. 

These t»/o points indicate that a unique apporach to 
creating the monitor's port driver must be considered. 
In particuler, it is ImDortart that the monitor be able 
to enqueue and dequeue command and response messages 
from the appropriate queues quickly. Several techniques 
are possible: 

1, fcnsure that the PCB is in a page that is mapped 
virtual to Physical, That is, if the PCB is in 
EXEC virtual page 100, then It must also be 

in Physical page lOO, it is also necessary 
to allocate BDs from pages with the same 
property. This restriction will not apply 
to the 2080 as it win provide instructions 
that Implement physical addressing, 

2, Since the monitor fenows the virtual address 
of the HCH, it can always reference it 
quickly. However, since it cannot predict which 
packet it needs to dequeue next, it needs a quick 
means of translating the physical address to a virtual 
one. The most straight-forward technique is for 

the port driver to have a virtual address slot 

it ff'By use for temporary mapping (the same kind 

of slot used in PAGEM e,q. CXBPG). when it needs 

to examine a packet, it would map the physical page 

to its Page slot, perforn. any data modifications 

or extractions, and clear the map slot. Since 

all queue headers and Interlock words are in fixed locations 

they can always be referenced witb virtual addresses, 

Despite the fact that the monitor always processes 

queues f-lFO, it still needs to Tialntaln 

both toTvarti and backward queue pointers since the 



port references aueues randomly, Therforc/ enqueulm 
or dequeueing a pacicet requires modifving another 
packet as well as a aueue header. To make this 
as efficient as possible, two temporary i»>ap 
slots could be allocated, 

3, Building in some other innate knowledge aeout SDs 
that would enable rapid conversion of physical 
addresses into virtual ones. An example would 
be to allocate all bds from a single exec virtual page 
thereby making the word offset In the physical 
page the unique identifer of the packet's location. 
Multiple pages could be used with another level 
of translation required. 

The first technique seems adeauate for the KLIO. The 2080 
provides sufficient flexibility In Its addresslna modes 
that the problem disappears. 



